Communications System

ABSTRACT

A method of providing services in a communication system. The method comprises: establishing a call instance from a caller terminal to a service provider terminal in the communication system; transmitting from the service provider terminal a service proposal in the form of an electronic document via the established call instance to the caller terminal; selectively accepting or rejecting the service proposal at the caller terminal; and in the case of acceptance of the service proposal, transmitting a request for money to a backend server in the communication system from the caller terminal; transmitting electronic cash tokens from the backend server to the caller terminal in response to the request to receive money; forwarding the electronic cash tokens from the caller terminal to the service provider terminal, whereafter the service provider provides services in accordance with the service proposal.

RELATED APPLICATIONS

This application is a divisional of and claims priority to U.S. patentapplication Ser. No. 12/006,054, filed Dec. 28, 2007, which claimspriority under 35 USC 119 or 365 to Great Britain Application No.0703759.1, filed Feb. 27, 2007 and Great Britain Application No.0704329.2 filed Mar. 6, 2007, the he entire teachings of the aboveapplications are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to service provision in a communicationsystem.

BACKGROUND

A communication system exists where calls can be established via apublic communication network such as the Internet using a peer-to-peercommunication system. Currently, a system exists under the trade markSkype which uses voiceover internet protocol (VoIP) packets to establishvoice calls between users of the system. Calls are established by clientsoftware executed at client terminals in the system. The client softwareestablishes a call instance between user terminals. A call instance canbe used to convey voice, video, IMS or other types of data. Suitableinternet packet protocols are used to convey the data.

Users of the system have in common the fact that they are all registeredwith a common provider of this system and this provides at least a firstlevel of familiarity between users. That is, to the extent that theprovider of the system monitors the behaviour of its users, there is acertain desirability of users of the system to want to deal with otherusers of the system as opposed to non users, where they need to access aservice.

SUMMARY

In providing a service in such a communication system, authorisation andsecurity issues need to be addressed.

The present invention provides a service provision system which makesuse of this communications network in a way which allows serviceproviders to ensure that they are paid for any service they provide tocallers in a way that does not require service providers to directlydemand cash from the callers themselves (with all of the problems thatthat could entail). In addition, security and authentication issues canbe readily addressed.

One aspect of the invention provides a service provider terminal forproviding a service the service provider terminal comprising: means fortransmitting as an electronic document a service proposal via a callinstance established between the service provider terminal and a callerterminal; and means for verifying the receipt of electronic cash tokensreceived from the caller terminal, said cash tokens indicating that acaller account has been debited for the service identified in theservice proposal.

The electronic document can carry an authentication code or security keywhich can be used to authenticate the service provider. In the describedembodiment the electronic cash tokens are signed in a cryptographicsense (that is they carry and authentication code), and can identify theservice proposal, the caller and the service provider.

Another aspect of the invention provides a caller terminal arranged toreceive services from a service provider terminal, the caller terminalcomprising: means for establishing a call instance between the callerterminal and the service provider terminal; means for receiving aservice proposal via the call instance and for forwarding the serviceproposal to a backend terminal; means for receiving electronic cashtokens from the backend terminal; means for forwarding the electroniccash tokens to the service provider terminal via the established callinstance; and display means for displaying to a user of the callerterminal the service proposal, said display means enabling the user toaccept or reject the service proposal.

The call instance can be any appropriate communication channel, e.g.wire call, private chat or public chat (where as is well known, a chatis typed messages that are exchanged over the network).

A further aspect of the invention provides a backend server comprising:means for receiving a service proposal relating to services to beprovided from a service provider to a caller in a communication systemin which the backend server is located; means for verifying the serviceproposal and for returning a verification message to a caller client;means responsive to a request for money from the caller client todetermine the credit status of the caller and to return electronic cashtokens to indicate that a caller account has been debited to meet thedemands of the service proposal. In the described embodiment, the valuerepresented by the cash tokens relates to the service provided—oneproposal can require several cash tokens.

The backend server can access a caller database which holds credit datafor callers, the credit data relating to available funds of each caller.

Another aspect of the invention provides a method of providing servicesin a communication system, the method comprising: establishing a callinstance from a caller terminal to a service provider terminal in thecommunication system; transmitting from the service provider terminal aservice proposal in the form of an electronic document via theestablished call instance to the caller terminal; selectively acceptingor rejecting the service proposal at the caller terminal; and in thecase of acceptance of the service proposal, transmitting a request forelectronic money to a backend server in the communication system fromthe caller terminal; transmitting electronic cash tokens from thebackend server to the caller terminal in response to the request toreceive electronic money; forwarding the electronic cash tokens from thecaller terminal to the service provider terminal, whereafter the serviceprovider provides services in accordance with the service proposal.

The invention also comprises a communication system including a callerterminal, a service provider terminal and a backend terminal as hereinabove described. The system also provides means to integrate with apayment mechanism for paying the service provider.

One aspect of this invention is provisioning payments using callinstances, for example VoIP channels. A “micro-payment” mechanism isimplemented to guarantee payments from prepaid caller accounts. Paymentsare related to services which are provided. In the described embodimentof this invention, services are provided via the call instance, but itwill be appreciated that the caller can pay the service provider toprovide any appropriate services, not necessarily those which areprovided over a call instance.

According to another aspect of the invention therefore there is provideda component configured to generate electronic cash tokens in the form ofpackets transmissible via a call instance, each token comprising acaller identifier, a service provider identifier, a proposal identifier,a monetary value and a cryptographic signature.

A further aspect provides a method of transmitting an indication that acaller account has been debited in a monetary value, the methodcomprising: generating electronic cash tokens in the form of packetstransmissible via a call instance, each token comprising a calleridentifier, a service provider identifier, a proposal identifier, amonetary value and a cryptographic signature; and transmittingelectronic cash tokens indicating the predetermined value via a callinstance established between two terminals in a communication network.

A further aspect provides a method of ensuring payment to a serviceprovider who provides a service to a buyer in accordance with a serviceproposal, the method comprising: generating electronic cash tokensdenoting a value sufficient to meet the demands of the service proposal;debiting a buyer account with that monetary value; and accruing thevalue debited from the buyer account to the service provider, whereinthe method is carried out at a third party terminal independent of botha terminal of the service provider and a terminal of the buyer.

Authentication is important in the premium calls system due tofundamentally conflicting interests of caller and service provider. Itallows the backend to communicate only with the buyer thereby reducingconnections to the backend server. The buyer is an intermediary betweenthe service provider and the backend. Both the service provider and thebackend therefore need to trust in the information coming from thebuyer, to ensure that it is genuine and has not been tampered with.

The proposal is sent from the service provider to the buyer, and this ispassed from the buyer to the backend. The proposal is preferably signedusing the identity of the service provider, to allow the backend toauthenticate the offer.

Similarly, when cash tokens are sent from the backend to the buyer, andfrom the buyer to the service provider the tokens are preferably alsoauthenticated (to ensure the buyer is not sending fake or replicatedmoney). A crypto handshake can be setup between the service provider andthe backend (via the buyer) using a shared context. In addition, thetokens themselves can be authenticated by the service provider usingmessage authentication codes.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention and to show how thesame may be carried into effect, reference will now be made by way ofexample to the accompanying drawings, in which:

FIG. 1 is a schematic block diagram illustrating a service provisionprocess;

FIG. 2 is a schematic diagram illustrating message exchange in theservice provision process;

FIGS. 2a-2f illustrate respective sub-components contained in FIG. 2,where each sub-component details portions of message exchanges andactions in the service provision process;

FIG. 3 is a schematic diagram of message exchange for transferringelectronic cash in a service provision system;

FIG. 4 is a schematic block diagram of the architecture of a serviceprovision system;

FIG. 5 is a schematic diagram of an electronic cash token; and

FIGS. 6 to 15 are screen shots showing the displays at a buyer terminaland service provider terminal during implementation of the serviceprovision process.

DETAILED DESCRIPTION

Reference will first be made to FIGS. 1 and 2 to describe a process inaccordance with one embodiment of the invention.

FIG. 1 is a schematic block diagram illustrating in schematic form thecomponents of a communication system which are involved in the process.

FIG. 2 is a message exchange chart which shows the components brokendown in more detail and the message exchange flow.

In FIGS. 1 and 2, similar reference numbers denote similar steps in theprocess. Moreover, where a step in the process is related to anotherstep, it is shown by that step number, annotated by a lower case letter.

According to step S1, a call is set up from a buyer at a buyer clientterminal 10 and a service provider at a service provider client terminal12. The client terminals form part of a communication network such asthe Internet. In a preferred embodiment of the invention, this call isset up in a peer-to-peer communication system. A peer-to-peer (P2P)communication system allows a call instance to be established across acomputer network such as the internet. In a currently available system,VoIP (voice over internet protocol) packets are used to transmit calldata between client terminals establishing the call instance. To use apeer-to-peer service, client software is installed and executed at theterminals. The client software provides a VoIP connection as well asother functions such as registration and authentication. In particular,for the purposes of authentication, a user of the system registershimself with a backend server which provides an authorisationcertificate to that user. When a call instance is established, theterminal receiving the call recognises the authentication certificateand so allows the call be established by the peer-to-peer network. Thedetails of this system are not given further herein because they areknown, for example from WO 2005/009019. It will be appreciated thatterminals can take any form. For example, they can be personal computers(PCs) executing the client software or mobile communication devices suchas phones, palmtops etc.

In the voice call, the buyer at the client terminal 10 can discuss withthe service provider at the client terminal 12 details of a servicewhich a service provider can provide to the buyer. If they agree theprinciples of a service to be purchased by the buyer, in accordance withstep S2 a price proposal is despatched from the client terminal 12 tothe client terminal 10. The service proposal (referred to herein as aprice proposal) is in the form of an electronic document which carriesan authentication code attached by the service provider. The electronicdocument is sent as packets using any suitable packet protocol.

At step S3 a prepContract message is prepared by the client's terminal10 and despatched to a backend server 14. The prepContract messageincludes the price proposal as a secure electronic document. As shownmore clearly in FIG. 2, a contract preparation message 300(convertedproposal, balance, proposal, SP, buyer), and implementsdetails of the price proposal. The message is forwarded to a ssp(Skype-to-Skype premium) gateway 14 a of the backend server 14 over thecommunications network using a proprietary protocol such as the Skypeprotocol. This is shown in step S3. The ssp gateway 14 a forwards (S3 a)the prepContract message to a backend server event queue component 14 b.A ssp database 16 a reads (S4 b) the message from the queue component 14b and verifies the service provider, checks for fraud and performs anynecessary currency conversion in relation to the contract. This isillustrated at step S4. Once satisfied, the ssp gateway 14 a transmits aproposal OK notification to the client terminal (S5) with the contract

As shown more clearly in FIG. 2, according to step S6 the price proposalis displayed to the buyer at the client terminal 10. Acceptance of thebuyer (as shown in step S6 a) is returned to the client running on theclient terminal 10 and an approval message shown as step S6 b isreturned to the service provider client 12.

When the buyer client terminal 10 receives a notification from thebackend server 14 that the proposal is OK, a get money request is sentfrom the client terminal 10 to the backend server 14 (step S7). The getmoney request is shown in FIG. 2 in the following format:

Get money (sequence number, money, proposal ID).

That is, it defines a sequence number for security reasons (discussedlater), an identifier of the proposal and the money value needed.

The get money request is received at the ssp gateway 14 a which forwardsa request to the backend server event queue (S7 a) in a form of a newrequest for credit. A ssp request handler component 14 c located in thebackend server reads a credit request from the backend server eventqueue 14 b and checks the credit of the buyer (step S8) with a userbalance database component 14 d at the backend server.

If the ssp request handler component 14 c ascertains that the credit isgood it despatches a message (debit OK) indicating that the buyer'saccount has been debited (S8 a). If it establishes that the credit isnot sufficient to meet the demands of the service proposal, itdespatches a message to the effect that the client could not be debited(debit NOK)—step S8 b. The debit OK and debit NOK messages are receivedby a feedback queue component 14 e in the backend server.

The ssp gateway 14 a reads the message from the feedback queue component14 e (S8 c).

If the message received from the backend server feedback queue 14 e is adebit OK message (S8 d), then money is returned to the buyer clientterminal 10 (step S9) in a form of cryptographically signed cash tokensprepared by the ssp gateway component 14 a.

The term “cash tokens” is used herein to denote tokens which allow anindication to be transmitted that a buyer's account has been debited ina certain value. They are not cash or money in any real sense. They canbe considered more as payment confirmations, in that they effectivelyguarantee that a payment will be made to the service provider inaccordance with the value which has been confirmed to the serviceprovider as having been debited from a buyer's account.

The cash tokens sent from the buyer terminal 10 to the service provider12 (S10) indicate that the buyer's account has been debited to meet thedemands of the price proposal with a view to providing payment to theservice provider. Information about the money accrued to serviceproviders is held in the ssp database 16 a.

When the service provider sees that the cash tokens have beentransmitted from the buyer he can then proceed to provide the serviceswhich have been agreed upon in the proposed contract based on the priceproposal at step S2. The services are provided over the channel set upfor the voice call. The services can be provided orally or can take theform of the transmission of digital information, such as still images,video etc. In fact, anything can be provided between the clients'terminals in accordance with the facilities which the communicationsystem provides. The provision of services is denoted diagrammaticallyat step S11 in FIG. 1. When the service provider has ceased to providethe service, the call is ended (step S12), and an end call notification(endContract) is sent to the backend server 14 (S13). This is important,because it may be the case that services are being charged for on atimed basis, and the end call notification indicates the time over whichthe services are being provided.

The ssp database 16 is in communication with a payment mechanism 100from which the service provider can receive payment (real money). Thispayment mechanism can advantageously take the form of the internetPaypal system if both the buyer and the service provider are signed upto that system. Other payment mechanisms are possible. What is importantis that the provider of the communication system pays the serviceprovider based on the money accrued to the service provider at the sspdatabase 17 a. This can be based on call data records which storeinformation on call detail.

Reference is now made to FIG. 3 to consider the transfer of cash tokensin more detail. FIG. 3 shows the step S7 of transmitting the get moneyrequest from the buyer client terminal 10 to the ssp gateway 14 a of thebackend server. If the ssp gateway recognises a proper context for theget money request, it returns the cash tokens at step S9. The cashtokens are then transmitted from the buyer client terminal 10 to theservice provider client terminal 12 (step S10).

A crypto-context is used for securing cash tokens sent from the sspgateway 14 a to the client terminal 10 and from there to the serviceprovider client terminal 12. The crypto-context is not used for securingmessages from the service provider to the ssp gateway. Thecrypto-context is conversation based (call-based). A service providerhas only one concurrent context per conversation (call). This means thata new crypto-handshake invalidates all cash tokens that the buyer hasrequested from the ssp gateway but has not yet passed to the serviceprovider. As shown in FIG. 3, a handshake for a new context is initiatedwhenever the ssp gateway feels that it does not have the necessarycontext to return cash tokens (step S9). As shown in FIG. 3, if nocontext is detected, a null message is returned to the buyer clientterminal 10 (step S15). A new context is requested between the clientterminal 10 and the client terminal 12 at step S16. There follows a newcrypto-handshake procedure denoted generally at step S17 which resultsin a new crypto-handshake denoted crypto-handshake 2 for returningcryptographically signed cash tokens (S17 b) which were requested by getmoney request using crypto-handshake 1 (step S17 a). Thecrypto-handshake 2 is RSA-signed with a special RSA key by a ssp-sign becomponent 14 f located at the backend server.

Reverting to FIG. 2, an option which has not been discussed already isshown in FIG. 2 for a buyer to generate a new contract directly based onthe previously agreed contract, and to send this to the ssp gatewaycomponent 14 a of the backend server. This is shown at step S18 in FIG.2. It also acts as an end contract message for the previous contracts.The ssp gateway forwards the message in a step denoted step S18 a.

FIG. 2 also shows a message (S20) which is transmitted in the case thata febroker has been lost between requests. This could be important tomaintain a solid crypto context between client and server.

In the above described example, the call instance is for a voice call.It will readily be appreciated that the call instance could be anyappropriate communication channel which is available for example overthe current peer-to-peer communication network implemented by Skype™.Thus, service proposals could be transmitted via a chat or public chatwhere there is no voice, but where typed messages are exchanged via datapackets over the network. The principles of this invention remain thesame in those other contexts.

FIG. 4 is a schematic diagram illustrating the components forimplementing the process discussed above. Some of these components havealready been illustrated and discussed in connection with FIGS. 1 to 3.

The buyer terminal client 10 is shown in communication with the serviceprovider client 12 by a call channel or call instance. As discussedabove, this can be implemented by using the peer-to-peer call mechanism.

In FIG. 4, the arrows between components which are labelled call denotea call functionality between components. The arrows which are labelled“use” denote that the component to which the arrow is headed suppliesdata to the component at the tail end of the arrow. The arrows labelled“send” transmit information in the direction of the arrow head from thesending component to the receiving component.

The ssp gateway component 14 a uses signatures from the ssp signbecomponent 14 f based on RSA keys held at the signbe component 14 f forauthentication purposes for the electronic documents and requests thatthe ssp gateway receives and transmits. The ssp gateway component 14 atransmits requests to the event queue 14 b as already discussed. The ssprequest handler 14 c takes the request and messages from the BES eventqueue 14 b and uses data from the balance database 14 d and the sspdatabase to fulfil the requests and supply responses to the BES feedbackqueue component 14 e. A backend server framework component 14 g is shownto handle calls which are established between the ssp gateway and thessp database, and to talk to queue components—note that not allconnections are shown for ease of clarity.

FIG. 4 also shows components associated with the payment mechanism 100in the implementation where that is a Paypal mechanism. Paypal is atrade name of a widely used web-based payment system. A web store 110can receive information from the ssp database 16 and from a userinformation database 112 for sign up with the Paypal server 114. FIG. 4also illustrates a provider revenue calculator component 116 whichcalculates revenue for the service providers and an order database 118whose function is not important.

As discussed above, the cash tokens must be signed by the ssp gatewayfor authentication and integrity. For this purpose an RSA key is storedat the ssp-signbe component 14 f and used to obtain a signature. Theservice provider client terminal verifies the signature by a shared keymechanism which is agreed with one-way authenticated Diffie-Hellman keyexchange. The security context is shared between the service providerterminal 12 and the backend server 14. The security context is setupafter the service provider registers as a service provider with thebackend server, and is updated as discussed in FIG. 3.

To prevent replay (or re-use) of cash tokens, the cash tokens include aservice provider identifier and a buyer identifier, which the serviceprovider client terminal checks. This avoids replay to a new serviceprovider. In addition, to avoid replay to the same service providerwithin the same call, the cash token includes a price proposalidentifier and a token sequence number. The service provider checks thatthe token sequence number does not repeat within the price proposalunder which services are being provided. To avoid replay to the sameservice provider within a future call, price proposals for the sameservice provider are unique within the predetermined time period, forexample a week. A check is done at the server side by the ssp gatewayand measured from the contract preparation to end contract message. Allissued cash tokens are set to expire within a period shorter than thepredetermined time period. One method for achieving expiration is toperiodically force a new crypto handshake (as shown in FIG. 3) from thessp gateway in order to invalidate all old tokens.

FIG. 5 is a schematic diagram of fields in a cash token. In addition tothe fields mentioned above, each cash token also includes a value field209 denoting the monetary value of the token.

In order to secure price proposal messages (sent in step S2), the priceproposals are RSA signed by a service provider user identificationcertificate (UIC key). The ssp gateway 14 a verifies the UIC key and thesignature before sending the contract preparation message 300 to the BESevent queue in step S3. The UIC serial number is checked from the userinfo database 112.

In order to achieve backend security, an RSA key pair is used forDiffie-Hellman key exchange between the service provider and the sspgateway 14 a. The backend server has an RSA key pair, private and publickey. The caller and service provider terminals have a hard coded (builtin) copy of the public key. The backend server uses the same key pairfor all crypto handshakes. The terminals use the same public key for allhandshakes. It will be appreciated that other security mechanisms arepossible.

The service provision system discussed herein can be suitablyimplemented on the existing peer-to-peer call communication system whichis currently available under the trade mark Skype. In that communicationsystem, software clients which are executed at the client terminalsalready have available to them a list of user names which can be used inthe present service provision system. That is, existing user names canbe used to identify both buyers and the service providers. Beforesigning up to the service provision system, it is advantageous that theuser already has a Paypal account but, as mentioned above, other paymentmechanisms are possible.

It is an important aspect of the service provision system discussedherein that calls are always initiated by a buyer and cannot beinitiated by a service provider. Any existing user of the currentcommunication system available under the trade mark Skype can sign up tobecome so-called premium service providers.

It will readily be apparent that price proposals can implement a numberof different pricing policies. For example, there could be a charge perminute of the call spent on providing the service, a charge per event ora combination of both. As already mentioned, if the currency requestedby the service provider in the price proposal differs from the currencyin which the buyer account is held, the ssp database at the backendserver takes care of converting the request currency to the buyeraccount currency using prevailing conversion rates.

Reference will now be made to FIGS. 6 to 15 to illustrate how thedisplays launched by the clients in the peer-to-peer communicationsystem for premium call service. The following are screen shots showingthe display launched by the software client which also handles theimplementing of call instances. According to FIG. 6, under the toolssection 300 of a toolbar launched by the client is a drop down menuwhich includes the option of 302 of “premium call service”. When theuser activates this field (for example using the cursor 304 and amouse), a display screen is provided to the customer as shown in FIG. 7which provides a field 306 for identifying a service, a drop down menu308 for identifying a charging policy and a field 310 for holding aprice dependent on the charging policy, that is per minute or per eventor both. An actuatable button 312 allows the addition of more services.

As already mentioned, it is a requirement in one implementation of thesystem that uses a Paypal payment mechanism that a Paypal account forthe service provider is created if it does not already have one. Thecreation of such a Paypal account is known already and is not discussedin more detail herein. For embodiments where other payment mechanismsare used, this is not required.

In order to initiate the process, a buyer selects a service providerfrom a list of service providers which is available to it. This list canbe launched through the client software which handles the call instancesof previously used service providers, or can be from any other source.As shown in FIG. 8, when the buyer initiates a call to a user 313 in hiscontact list, the identity and image of the service provider (user) hehas called is displayed in an image field 319 to the buyer at its clientterminal 10. FIG. 9 illustrates the view launched by the client to theservice provider at this point. That is, the service provider knows thata call is being made to it from the screen 317. The service provideranswers the call and the dialogue discussed above ensues to agree aprice/service proposal. FIG. 10 illustrates the display launched by theclient of the service provider in order to allow it to select a serviceand charge rate. A field 314 holds a per minute charge for a firstservice (in this example how to make a pin cushion) and a field 316holds a one-off fee for a second service. The service providerdispatches a price proposal (step S2) to the buyer client terminal 10and FIG. 11 shows the display that is launched at the buyer clientterminal 10 (after the backend server has verified the proposal (S3 toS5)) to accept or reject the price proposal. That is, the display showsthe terms of the price proposal at 318 including an accept button 320labelled “pay” and a reject button 322. Once the buyer has accepted(FIG. 12—(ref. 321)) the terms his display changes to show that the feehas been accepted and the display at the service provider terminal 12changes also to show that the fee has been accepted as illustrated inFIG. 13, ref. 323.

The billing procedure is then initiated (step S7) and assuming that thebuyer has sufficient credit to cover the price proposal, cash tokens arereceived from the backend server and conveyed to the service provider(step S9, S10). The service provider is notified accordingly and canproceed to provide the service. If the buyer does not have sufficientcredit, the client at the buyer client terminal launches the displayshown in FIG. 14 indicating that he does not have enough credit (328).The client terminal at the service provider similarly displays to theservice provider that the caller does not have enough credit (FIG. 15,ref 329). There is therefore no need for the service provider tocontinue the call and provide the service unless he wishes to do sounpaid. In this system, the service provider does have this option.

It is noted that although the above described embodiment assumes that abuyer account has prepaid credit, any number of alternatives arepossible, for example post-paid, corporate accounts or real-time top up.

While this invention has been particularly shown and described withreferences to example embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

1. (canceled)
 2. A server comprising: at least one processor; and one ormore hardware computer-readable storage devices storing processorexecutable instructions which, responsive to execution by the at leastone processor, are configured to enable the server to perform operationscomprising: receiving, from a caller client terminal in a communicationsystem and over a network, a service proposal identifying one or morecommunication services to be provided by a service provider server inthe communication system, the service proposal including one or moreconditions associated with providing the one or more communicationservices; authenticating the service proposal from the caller clientterminal based, at least in part, on authenticating the service providerserver; responsive to authenticating the service proposal, generating averification message that indicates whether the service proposal wasauthenticated; returning, to the caller client terminal and over thenetwork, the verification message; responsive to returning theverification message, receiving, from the caller client terminal andover the network, a request to verify whether the one or more conditionsassociated with the service proposal are met by a caller accountassociated with the caller client terminal; determining whether thecaller account is able to support the one or more conditions; responsiveto determining the caller account is able to support the one or moreconditions, obtaining one or more encrypted electronic tokens associatedwith supporting the one or more conditions; and returning, to the callerclient terminal and over the network, the one or more encryptedelectronic tokens to forward to the service provider server, the one ormore encrypted tokens configured to enable the service provider serverto validate the one or more encrypted electronic tokens prior toproviding the one or more communication services.
 3. The server asrecited in claim 2, wherein determining whether the caller account isable to support the one or more conditions further comprises: accessinga database comprising information associated with a plurality of calleraccounts, at least some of the information comprising a statusassociated with the caller account that indicates whether the calleraccount is able to support the one or more conditions.
 4. The server asrecited in claim 2, wherein authenticating the service proposal furthercomprises: using an identity associated with the service provider serverto verify a signature applied to the service proposal.
 5. The server asrecited in claim 2, wherein each encrypted electronic token of the oneor more encrypted electronic tokens comprises at least one of: a calleridentifier associated with the caller client terminal; a serviceprovider identifier associated with the service provider server; aproposal identifier associated with the service proposal; a valueassociated with the respective encrypted electronic token; or acryptographic signature.
 6. The server as recited in claim 2, whereinthe one or more encrypted electronic tokens are each cryptographicallysigned based on a crypto-context handshake used between the server andthe service provider server.
 7. The server as recited in claim 2,wherein at least one communication service of the one or morecommunication services is a time-based service.
 8. The server as recitedin claim 2, wherein the operations further comprise: identifying acontext associated with the service proposal; determining the calleraccount is unable to support the one or more conditions based, at leastin part, on the context; and returning, to the caller client terminaland over the network, a null message in response to determining thecaller account is unable to support the one or more conditions.
 9. Amethod comprising: receiving, at a server and from a caller clientterminal over a network, a service proposal identifying one or morecommunication services to be provided by a service provider server in acommunication system, the service proposal including one or moreconditions associated with providing the one or more communicationservices; authenticating the service proposal from the caller clientterminal based, at least in part, on authenticating the service providerserver; responsive to authenticating the service proposal, generating averification message that indicates whether the service proposal wasauthenticated; returning, to the caller client terminal and over thenetwork, the verification message; responsive to returning theverification message, receiving, from the caller client terminal andover the network, a request to verify whether the one or more conditionsassociated with the service proposal are met by a caller accountassociated with the caller client terminal; determining whether thecaller account is able to support the one or more conditions; responsiveto determining the caller account is able to support the one or moreconditions, obtaining one or more encrypted electronic tokens associatedwith supporting the one or more conditions; and returning, to the callerclient terminal and over the network, the one or more encryptedelectronic tokens to forward to the service provider server, the one ormore encrypted electronic tokens configured to enable the serviceprovider server to validate the one or more encrypted electronic tokensprior to providing the one or more communication services.
 10. Themethod as recited in claim 9, wherein determining whether the calleraccount is able to support the one or more conditions further comprises:accessing a database comprising information associated with a pluralityof caller accounts, at least some of the information comprising a statusassociated with the caller account that indicates whether the calleraccount is able to support the one or more conditions.
 11. The method asrecited in claim 9, wherein authenticating the service proposal furthercomprises: using an identity associated with the service provider serverto verify a signature applied to the service proposal.
 12. The method asrecited in claim 9, wherein each encrypted electronic token of the oneor more encrypted electronic tokens comprises at least one of: a calleridentifier associated with the caller client terminal; a serviceprovider identifier associated with the service provider server; aproposal identifier associated with the service proposal; a valueassociated with the respective encrypted electronic token; or acryptographic signature.
 13. The method as recited in claim 9, whereinthe one or more encrypted electronic tokens are each cryptographicallysigned based on a crypto-context handshake used between the server andthe service provider server.
 14. The method as recited in claim 9,wherein at least one communication service of the one or morecommunication services is a time-based service.
 15. The method asrecited in claim 9, wherein the operations further comprise: identifyinga context associated with the service proposal; determining the calleraccount is unable to support the one or more conditions based, at leastin part, on the context; and returning, to the caller client terminaland over the network, a null message in response to determining thecaller account is unable to support the one or more conditions.
 16. Oneor more computer-readable memory devices comprising processor-executableinstructions which, responsive to execution by at least one processor,perform operations comprising: receiving, at a server and from a callerclient terminal over a network, a service proposal identifying one ormore communication services to be provided by a service provider serverin a communication system, the service proposal including one or moreconditions associated with providing the one or more communicationservices; authenticating the service proposal from the caller clientterminal based, at least in part, on authenticating the service providerserver; responsive to authenticating the service proposal, generating averification message that indicates whether the service proposal wasauthenticated; returning, to the caller client terminal and over thenetwork, the verification message; responsive to returning theverification message, receiving, from the caller client terminal andover the network, a request to verify whether the one or more conditionsassociated with the service proposal are met by a caller accountassociated with the caller client terminal; determining whether thecaller account is able to support the one or more conditions; responsiveto determining the caller account is able to support the one or moreconditions, obtaining one or more encrypted electronic tokens associatedwith supporting the one or more conditions; and returning, to the callerclient terminal and over the network, the one or more encryptedelectronic tokens to forward to the service provider server, the one ormore encrypted electronic tokens configured to enable the serviceprovider server to validate the one or more encrypted electronic tokensprior to providing the one or more communication services.
 17. The oneor more computer-readable memory devices as recited in claim 16, whereindetermining whether the caller account is able to support the one ormore conditions further comprises: accessing a database comprisinginformation associated with a plurality of caller accounts, at leastsome of the information comprising a status associated with the calleraccount that indicates whether the caller account is able to support theone or more conditions.
 18. The one or more computer-readable memorydevices as recited in claim 16, wherein authenticating the serviceproposal further comprises: using an identity associated with theservice provider server to verify a signature applied to the serviceproposal.
 19. The one or more computer-readable memory devices asrecited in claim 16, wherein each encrypted electronic token of the oneor more encrypted electronic tokens comprises at least one of: a calleridentifier associated with the caller client terminal; a serviceprovider identifier associated with the service provider server; aproposal identifier associated with the service proposal; a valueassociated with the respective encrypted electronic token; or acryptographic signature.
 20. The one or more computer-readable memorydevices as recited in claim 16, wherein the one or more encryptedelectronic tokens are each cryptographically signed based on acrypto-context handshake used between the server and the serviceprovider server.
 21. The one or more computer-readable memory devices asrecited in claim 16, wherein the operations further comprise:identifying a context associated with the service proposal; determiningthe caller account is unable to support the one or more conditionsbased, at least in part, on the context; and returning, to the callerclient terminal and over the network, a null message in response todetermining the caller account is unable to support the one or moreconditions.